Intelligent keyfob management system

ABSTRACT

An intelligent keyfob management system ( 300 ) is disclosed. The system ( 300 ) includes the steps of: sending ( 302 ) a RF signal having unique serial data from a transmitter; receiving ( 304 ) RF signal in a receiver and converting the RF signal to a digital signal; transmitting ( 306 ) the digital signal with the unique serial data from the receiver to a microcontroller; providing ( 308 ) an editable microcontroller memory including a look up table accessible by an external programming device; verifying ( 310 ) whether the unique serial data from the transmitting step matches data populated in the look up table; and performing or refraining from performing ( 312 ) a command requested by the transmitter, based on the data in the look up table. 
     The system ( 300 ) is particularly adapted for use with security locks for containers, trailers, and delivery systems using emergency exit doors, and provides an enhanced tool in managing, monitoring and administering RF devices, and particularly keyfobs, typically from a remote or dispatch office location. The look up table can be used to program when an RF device or keyfob is operable or non-operable, and a logging feature can time stamp each device&#39;s usage or attempted usage, for later retrieval and analysis, which can be useful for management of RF device fleets and field and delivery personnel.

BACKGROUND

This invention relates to security systems using radio frequency (RF)receivers and transmitters to control the system operation, includinglocking and unlocking, door opening and closing processes, tools, andcustom software and hardware to manage, administer and monitor a fleetof RF devices.

The RF transmitters and receivers have been used for years to controlsecurity systems, such as automatic locks and door openers. All suchsystems have certain limitations. The main ones are: limited number oftransmitters in a system (usually less than 50), inability to identifywhich transmitter was used in a particular operation, inability toenable and disable or remove a single transmitter out of severalprogrammed for the RF system, inability to log not only performed tasks,but also attempts to use disabled transmitters.

It would be beneficial if a manager could program or pre-select time foreach transmitter, when it is enabled and disabled, so that, for example,1^(st) shift worker could use their transmitters during that shift only.

It would also be considered beneficial, if users were periodicallyrequired to enter passwords or a short sequence of key entries to keeptheir transmitters activated for predetermined amount of time (a workday, for example). If any of them fails to enter the sequence, thetransmitter would be disabled. The addition of all these extra featurescan significantly increase security and reduce unwanted access to cargobeing protected by the security system.

A need also exists for a security system that stores a number of eventrecords, such as records of RF transmitter usage, including their serialnumbers, and records of the unlocking, locking, door opening or closing,and date, time, air temperature, and/or geographical location of thoseevents. The records need to be updated in such a way, that the new oneswould replace the oldest ones, as soon as the maximum number of recordsallowed was reached.

Furthermore, a need exists for the electronic control system tocommunicate with an outside world through a unique serial protocol, andprovide a user a secure two-way connection using commercially availabledevices, such as a personal computer (PC), cellular or dial-up modem, orInternet connection, as well as an RF modem. A need exists for a PCsoftware program to communicate with the electronic controller, updateits software, adjust features, enable/disable and program input andoutput devices, calibrate, diagnose problems, and retrieve informationrecords. The user should be able to protect access to the securitysystem by setting and maintaining software passwords.

SUMMARY

The disclosed apparatus and methods avoid some of the disadvantages ofprior devices and add new features. Methods of secure RF communicationare already widely used, employing highly secured algorithms, such asKEELOQ® to prevent unauthorized access. Room for improvement exists inpost-processing of the decoded data. The invention described hereinprovides a significant enhancement to this process. Users are allowed toemploy a significantly larger number of transmitters, identify each ofthem, assign names or numbers to them, and record their actions in anevent log. Retrieving the recorded log with a personal computer (PC) orPDA allows the user to gather significant data on performance of thewhole security system. A typical electronic system for cargo security,its operation, storage of events, retrieval of events, PC softwarecommunication program, and licensing process are described in the U.S.Pat. No. 7,091,857 (Electronic Control System Used in Security Systemfor Cargo Trailers), and the system described below represent asignificant enhancement to that system. It is assumed, herein, that thereader is familiar with the text of that US patent, so the descriptionused there does not need to be repeated.

The addition of a serial communication link between the RF receiver andthe microcontroller controlling the system operation allows an easytransfer of data and switches the keyfob processing from the RF receiverto the microcontroller. The keyfob information is kept in themicrocontroller memory and it is continuously available to the controlprogram. The control program also takes care of data verification andfault management, therefore there is a better chance that the systemwill recognize a partial or corrupted RF transmission and take anappropriate action. An extra backup copy of the keyfob table could bekept in the microcontroller's memory to be used in case of the datacorruption of the main table to recover from the fault. If a GlobalPositioning System (GPS) receiver is connected to the system, keyfobevent recording can be followed by the location events for furtherprocessing, so that the user knows the serial number of the keyfob, andexact time and location of its use.

A more detailed explanation of the invention is provided in thefollowing description and claims, and is illustrated in the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

For the purpose of facilitating an understanding of the subject mattersought to be protected, there are illustrated in the accompanyingdrawings embodiments thereof, from an inspection of which, whenconsidered in connection with the following description, the subjectmatter sought to be protected, its construction and operation, and manyof its advantages should be readily understood and appreciated.

FIG. 1 is a typical RF keyfob based control system block diagram;

FIG. 2 represents a typical RF receiver processing flowchart;

FIG. 3 represents an enhanced RF keyfob based control system blockdiagram, in connection with the instant invention;

FIG. 4 represents an enhanced RF receiver processing flowchart, inconnection with the instant invention;

FIG. 5 represents a microcontroller keyfob processing flowchart, inconnection with the instant invention;

FIG. 6 is the second part of the microcontroller keyfob processingflowchart, in connection with the instant invention;

FIG. 7 represents a keyfob table record structure, in connection withthe instant invention;

FIG. 8 represents a typical work schedule entry, in connection with theinstant invention;

FIG. 9 shows keyfob management log entries, in connection with theinstant invention;

FIG. 10 represents a possible PC keyfob table processing screen, inconnection with the instant invention;

FIG. 11 shows a typical keyfob record screen, in connection with theinstant invention; and

FIG. 12 represents an enhanced custom RF device and keyfob systemflowchart, in connection with the instant invention.

DETAILED DESCRIPTION

Turning now to the drawings, and more particularly, FIG. 1 thereof,there is a typical RF keyfob system, used in many applications,including security systems, automatic locks, and door openers. Itcontains an RF receiver 100, several RF transmitters 102,microcontroller 104 with sensors (inputs) 106, actuators (outputs) 108,event memory 103, power management unit 105, real time clock 101, andcommunication interface 107, such as RS-232. Not shown, but potentiallyincluded in such system is a GPS device to provide a location. Thetransmitters 102 contain one or more pushbutton switches and anelectronic circuit to detect switch activations, create serial messages,possibly encrypt them using one of the encrypting schemes (for exampleKEELOQ®), and send them out using radio frequency link. There may beseveral (sometimes as many, as 50) independent transmitters 102 workingwith one receiver 100 in the system, each transmitter with the uniqueserial number. One transmitter can also work with unlimited number ofreceivers, since each receiver could be programmed independently.

In order to be recognized by the RF keyfob based control system fromFIG. 1, the RF transmitters 102 need to be programmed into the RFreceiver's 100 memory. When the RF transmission is received (FIG. 2),the receiver converts the RF to digital transmission at 110, verifies at112 if the transmitter's serial number is in its memory, decrypts themessage (if necessary) at 114, and verifies if the transmission isvalid, by checking the sync counter value at 116. If the sync counter isused, it is updated at 118, and if the counter is out of sync, the RFreceiver stores its present value at 122 for future resynchronizationattempt. If the transmission is valid, the RF receiver 100 sends anappropriate digital output at 120 to the microcontroller 104.

The microcontroller 104 uses the RF receiver's digital signals, as wellas other inputs from sensors 106, to control the system, via actuators108. It also uses event memory 103 to store events, real time clock 101for time stamp, and potentially a GPS receiver for the location stamp.

Referring to FIG. 3, the instant invention relates to an RF devicemanagement system, and preferably an intelligent custom keyfobmanagement system adapted for use in connection with security locks,emergency exit doors and the like. The system can include: amicrocontroller, an RF receiver, RF transmitters, a serial link betweenthe RF receiver and microcontroller, input sensors including GPSposition, output actuators, communication interface, event memory, realtime clock, power management system to control power sources: main powerand battery backup. As shown in FIGS. 3-11, the instant inventionprovides custom software to manage and administer RF devices,transmitters, transceivers, keyfobs and the like, remotely or in thefield, and is particularly useful in connection with keyfobsindependently entered in a look up table, by for example, enabling anddisabling certain keyfobs, programming when a desired keyfob is operable(i.e. during assigned work hours) or non-operable (i.e. during offhours), and logging each event or attempted event for later retrievaland analysis.

Referring to FIG. 3, an intelligent keyfob management system is shown.The system can include: an RF receiver 100, several RF transmitters 102,microcontroller 104 with sensors (inputs) 106, actuators (outputs) 108,event memory 103, power management unit 105, real time clock 101, andcommunication interface 107, such as RS-232. Not illustrated in thefigures, an optional GPS receiver is included to provide a locationstamp for the event log. The RF receiver 102, in addition to standardprocessing of the RF transmissions, sends the serial data 109 to themicrocontroller 104. This happens even if the transmitter's serialnumber is not stored in the receiver's memory and the standardprocessing does not send any digital output signals. The serial datatransmission 109 contains: the transmitter serial number, the synccounter value, the command requested, and optionally, a transmitter lowbattery warning. The microcontroller 104 has all digital data from thetransmitters 102, necessary to process the transmission independently ofthe RF receiver 100.

FIG. 12 represents an enhanced, intelligent custom RF device and keyfobsystem flowchart. The custom keyfob management system (300) includes thesteps of: sending 302 a RF signal having unique serial data from atransmitter; receiving 304 RF signal in a receiver and converting the RFsignal to a digital signal; transmitting 306 the digital signal with theunique serial data from the receiver to a microcontroller; providing 308an editable microcontroller memory including a look up table accessibleby an external programming device; verifying 310 whether the uniqueserial data from the transmitting step matches data populated in thelook up table; and performing or refraining from performing 312 acommand requested by the transmitter, based on the data in the look uptable.

The custom or intelligent system 300 is particularly adapted for usewith security locks for containers, trailers, and delivery systems usingemergency exit doors, and can include: a microcontroller, an RFreceiver, several RF transmitters, a serial link between the RF receiverand microcontroller, input sensors including GPS position, outputactuators, a communication interface, event memory, real time clock, andoptionally, a power management system to control power sources: mainpower and battery backup. The custom system 300 provides an enhancedtool in managing, monitoring and administering RF devices, andparticularly keyfobs, typically from a remote or dispatch officelocation. Preferably, a look up table can be used to program when an RFdevice or keyfob is operable or non-operable, and logging each device'susage or attempted usage, for later retrieval and analysis can be usefulfor management of RF device fleets and field and delivery personnel.

FIG. 4 shows the enhanced RF receiver processing. It should be noted,that a major difference from that shown in FIG. 2, is that in FIG. 4,the receiver decrypts the sync counter and the command at 114 beforechecking the serial number at 112, because the serial data 109 is sentto the microcontroller 104 all the time, either at 124, or at 126. Ifthe transmitter's serial number is stored in the receiver's memory, thereceiver 100 can process data and send the appropriate digital signaloutput. In that case, the serial transmission data at 126 sent to themicrocontroller can be used for additional processing, for example toadd the transmitter's serial number to the event log and enhancereporting of events. The receiver 100 verifies if the transmission isvalid, by checking the sync counter value at 116. If the sync counter isused, it is updated at 118, and if the counter is out of sync, the RFreceiver stores its present value at 122 for future resynchronizationattempt. If the transmission is valid, the RF receiver 100 sends anappropriate digital output at 120 to the microcontroller 104.

If the transmitter's serial number is not in the receiver's memory at112, the serial transmission data is still sent at 124, and totalprocessing is entirely done by the microcontroller 104. In this case,the function of the RF receiver 100 is limited to converting the RFsignals and decrypting data. The serial transmission data 109 mayinclude a special character to indicate whether it is “known” or“unknown” to the receiver. For example, it could be a character “K” for“known” and “U” for “unknown”, but any other choice is allowed.

FIG. 5 shows the keyfob serial data transmission processing by themicrocontroller 104. The data is received at 130 and checked for “known”or “unknown” characters at 132. If a “known” keyfob is being processedat 136, the command is already executed by the receiver's digitaloutput, and the only task left is to record the event in the log at 138,if desired. If an “unknown” keyfob is detected at 134, its processing isshown in FIG. 6.

FIG. 6 represents the keyfob processing at the microcontroller level.After receiving the serial transmission from the RF receiver 100, themicrocontroller 104 checks if the keyfob serial number is included inthe keyfob look up table at 140. If not, the microcontroller 104verifies if a learn (Discovery) mode is active at 162. If so (yes), themicrocontroller forwards the entire serial transmission to a personalcomputer (PC) or a network server at 164 for further processing,including a keyfob look up table creation.

If the keyfob serial number exists in the keyfob table at 140, the synccounter is verified at 142. If the newly received sync counter value isnot correct, the microcontroller 104 stores it at 144 in an attempt toresynchronize the counter, otherwise the previously stored value of thesync counter is updated at 146. Next, the pushbutton command isvalidated at 148 and keyfob battery information is retrieved at 150. Ifthe battery voltage is low, a low battery flag is set at 152. There areother factors at 154 described later, which affect the keyfob byenabling and disabling its operation. If the keyfob is enabled, thecommand is executed at 158 and the action is recorded in the log at 160.Otherwise, only the attempt to use the keyfob is recorded at 156. If thelearn mode is active, the serial transmission is always passed at 164 tothe PC.

In order for the keyfob to be recognized by the microcontroller 104, itneeds to be entered in the keyfob look up table in the microcontroller'smemory. The keyfob look up table can contain a large number of records,such as 1024 or more.

FIG. 7 illustrates a possible keyfob table record structure. Forexample, the record contains 16 bytes of data including: keyfob serialnumber 170, attributes 172, work schedule pointer 174, use counter 176,sync counter 178, auxiliary sync counter 180, and CRC (cyclic redundancycheck) or checksum data 182 for verification of integrity of the record.The keyfob serial number 170 is unique for each transmitter or keyfob,and it is 4 bytes long in this example. The one-byte attributes maycontain: enable bit 184, lost/stolen bit 186, sync required bit 188,pass code bit 190, new keyfob bit 192, and low keyfob battery bit 194.The user or administrator can enable the transmitter by setting the bit184, or can disable if one is reported as lost or stolen by setting thebit 186. If the out of sync keyfob is used, the microcontroller sets thebit 188 and stores the current transmitter's sync counter in theauxiliary sync counter 180. If the next transmission provides thecorrect sync counter value, the bit 188 is cleared and the correct synccounter value is transferred to the sync counter 178.

If there is a new transmitter added to the system, the bit 192 is set.Thus, in this way, the microcontroller 104 knows that resynchronizationis needed right away to get the correct value of the sync counter 178.The keyfob transmission may contain a bit indicating low transmitterbattery—in that case the bit 194 is set.

The pass code bit 190 could be used as an additional keyfob enable bit.The user may be required to enter a password, such as a sequence ofpushbutton activations, periodically, for example, every morning to setthe bit 190 and enable the transmitter for that day. If a two-buttontransmitter is used for example, the user may need to press the rightbutton two times, then the left button once, and finally the rightbutton again. The entire sequence must be completed within a certaintime period, such as 15 seconds, to set the bit 190 and enable thisparticular keyfob for the next 8-hour shift. It should be obvious tothose skilled in art, that pushbutton sequence, number of keyfobactivations in a sequence, time to enter the sequence, and bit 190enable duration can be altered in this system, without departing fromthe scope of this invention.

The keyfob table also includes a one-byte work schedule pointer 174 witha value from 0 to 255. Stored in the microcontroller 104 memory (locatedin either internal, or external event memory 103) are up to 256 tables,like the one shown in FIG. 8 example. Each table entry corresponds totwo hours of work—there are enough entries in the single work scheduletable to cover the whole week. Zeros in the table are meant to disablethe keyfob operation, and ones—to enable it. Therefore, the FIG. 8 workschedule example indicates that only the first 8 hours each day fromMonday to Friday are enabled. The user can switch the table by changingthe work schedule pointer value 174. The work schedule tables could bepreprogrammed by the manufacturer in the program memory, or they canalso be input in data memory by a user, for greater flexibility.

Referring back to FIG. 7, a CRC or a checksum register 182 is shown,which is used to verify each record integrity. Different methods couldbe used for that purpose, but all of them need to be able to indicatethat the keyfob table record is corrupted. The microcomputer should beprogrammed to manage individual record's corruption, by at leastdisabling its use, or better, by repairing the problem. The easiest wayto deal with corrupted records is to keep a redundant (backup) keyfobmanagement table in a different memory location, and keep the backupcopy continuously updated. If the corrupted record is encountered in themain table, the backup copy could be utilized and the problem recordedin the log, or the backup, if correct, could be used to repair the maintable record. If both records are corrupted, microcontroller softwarecould be developed to analyze both entries and try to recreate thecorrect record values, since it is unlikely that both records arecorrupted the same way.

When the microcontroller based keyfob management system is used, forexample, the microcontroller 104 stores the keyfob related events in acertain format, shown in FIG. 9. Since the log event memory space may belimited and additional data, such as voltages, temperature, systemstatus, and event time stamp, need to be recorded, it is advantageous tocreate a special event format, like the one shown in FIG. 9. There aregeneral keyfob management events 206 (not related to a particular keyfobserial number), for example when the keyfob table is read by the PC, orthe keyfob table size is written to the microcontroller event memory103, after updating table entry records. The time stamp used for theseevents is 5-bytes long, without a byte for a year, to limit the eventdata to 8 bytes for easy processing at the microcontroller level. Theyear could be added by the PC program, when it processes other eventscontaining the full 6-byte time stamp. Additionally, there are keyfobevents related to a particular serial number, for example locking adoor. These events require more memory space since the serial numbercould be as long as 3, or even 4 bytes. FIG. 9 assumes that the eventsusing keyfob serial numbers are 16 bytes long and the first 8 bytes 200contain: event name, system status byte, main and auxiliary voltages,4-bit attributes 204, and a 3.5 byte long serial number. The remainingbytes 202 contain: event name (indicating that it is an extension of akeyfob related event), temperature, and a 6-byte long time stamp, whichincludes month, day, year, hour, minute, and second. The attributes 204contain 4 bits transferred from the keyfob table (FIG. 7): a low batterybit, enable bit, lost/stolen bit, and sync required bit. The first 3bits of attributes 204 are direct transfers of bits 194, 184, and 186.The last bit is a logic sum of bits 188 and 192.

If the system uses a GPS receiver, there are additional log entriesrelated to the GPS position when a keyfob is used. FIG. 9 shows forexample a possible GPS entry record 207. This record contains: eventname, GPS latitude (degrees), GPS longitude (degrees), GPS latitude(fraction of degrees), GPS longitude (fraction of degrees), and powersupply voltage. This record format allows the full GPS position stamp tostay within 8 bytes limit for compatibility with other types of events.Additionally, in a preferred embodiment, the format is compatible withindustry standard mapping programs, such as MapQuest, to display the GPSposition on a map.

FIG. 10 depicts a possible keyfob table processing PC program screen. Auser opens the screen 210 and at this point has three choices: (i) readthe keyfob table from the microcontroller 104, (ii) load a previouslysaved table from a computer file, or (iii) create a new table by typingnew keyfob serial numbers at 233 and pressing the “Add Keyfob” button232. To read the table from the microcontroller's memory the userselects “Read Keyfob Table” 222, and to load the saved list from a filethe button “Load List from File” 246 has to be selected. Once the listof keyfobs is displayed on the screen, it can be edited. The list caninclude the following columns: serial numbers 212, work schedule 214,attributes (enable, lost, new, sync request), and use counter 216.Additionally, if the keyfob table is read from a file, it may containnames of keyfob users at 218 and keyfob numerical ID's at 220. Once thetable is displayed, the user can “Add Keyfob” by typing new serialnumbers and selecting 232. The user can highlight a line in the tablecontaining a particular keyfob entry and use the “Delete Keyfob” buttonat 234 to remove that entry. Additionally, a user can perform searchesat 236 and 240 for a particular keyfob entry, and verify which keyfobentries in the displayed table correspond to the actual table stored inthe microcontroller's memory, by pressing the “Sync List with Lock”button 238. The synchronized entries can be highlighted and displayed ina different color than the ones that have been changed.

Once the user is done editing the keyfob list, he or she can overwritethe entire table in the microcontroller's memory, by pressing the“Overwrite Keyfob Table” button 226, or update the selected single entryby pressing the “Update Selected” button 228. Numbers of keyfobs in eachtable are displayed at 224—if the list displayed on the screen has adifferent number of keyfobs, the entire microcontroller table needs anupdate, since the microcontroller 104 requires the keyfob table entriesto be sorted by serial numbers for speedy searches, when the RF signalis received.

The displayed keyfob table can be saved into a file by pressing the“Save List to File” button 244, and also opened by a spreadsheetprogram, such as MS Excel for further processing, by pressing the “OpenList File in Excel” button 242. The Excel file, if its format has notchanged, could be loaded back to the table by pressing the “Load Listfrom File” button 246.

Different colors could be used for table records, to indicatemodifications, keyfob low battery, or errors in data or record format—alegend at 230 can provide a color explanation for the user.

As earlier mentioned, there is a learn (Discovery) mode selected bychanging or setting a position on a toggle like switch 248. If the learnmode is activated, the PC software sends a command to themicrocontroller to pass the keyfob serial transmissions to the PCprogram. The newly received serial numbers from the microcontroller areadded to the list at 212, and the list is automatically sorted based onall keyfob serial numbers. If the serial number coming from themicrocontroller is already on the list 212, it is highlighted and amessage is provided. If the user selects a “Read Only” mode at 250, thelearn (Discovery) mode is limited to highlighting the existing keyfobserial numbers, without adding the new ones to the list—the user will bewarned that the keyfob just used is not on the list. This featureprotects the user from adding new keyfobs to the table, when theintention was only to identify the serial numbers, or the user's namesassigned to certain keyfobs.

The keyfob list can contain large number of entries, such as 1024 ormore, therefore one cannot assume that serial numbers could be easilyfound, and changes seen. To protect the user from unintentional changes,the read-only mode and a warning message system can be implemented.

FIG. 11 depicts a possible implementation of the 16-byte keyfob tableevent record display by the PC program screen. The name of the event isshown at 260, as well as the exact time stamp and the keyfob serialnumber. The security system status is shown at 262, voltages andtemperature at 264, the keyfob battery status at 266, and keyfobattributes at 268.

The control system with the new keyfob management may use asound-creating device, such as a buzzer, to communicate to a user thecurrent system condition, request acknowledgements, and diagnosticinformation. The system may also utilize a battery backup to operate thekeyfobs and all security devices when the main power is disconnected, ornot sufficient. The system can be designed to operate from the mainpower source even if its voltage is lower than the backup batteryvoltage, to extend the backup battery useful life. The microcontroller104 is designed to control through its power management circuit 105 thecharging of the backup battery, if the main power source voltage meetsan appropriate threshold. If below a certain threshold, no chargingoccurs, and if above charging is enabled.

The microcontroller 104 is also designed to communicate through itscommunication interface 107 with a computing device, such as a personalcomputer, a modem, a wireless link, a PDA or the like. In a preferredembodiment, the computing device uses a serial link, such as RS-232,RS485, USB, or any other available communication link. The user may needto obtain a software license to be able to establish communicationbetween the microcontroller and the computing device mentioned above. Atypical PC software communication program and licensing process isdescribed in the U.S. Pat. No. 7,091,857 (Electronic Control System Usedin Security System for Cargo Trailers), and is hereby incorporatedherein by reference.

In its simplest form, a custom RF device management system is shown anddisclosed in FIGS. 3-11. It is particularly adapted for use inconnection with keyfobs. The system has at least one RF transmitter, aRF receiver and a microcontroller, and comprises the steps of: sending aRF signal having unique serial data from a transmitter; receiving the RFsignal in a receiver and converting the RF signal to a digital signal;transmitting the digital signal with the unique serial data from thereceiver to a microcontroller; providing an editable microcontrollermemory including a look up table accessible by an external programmingdevice; verifying whether the unique serial data from the transmittingstep matches data populated in the look up table; and performing orrefraining from performing a command requested by the transmitter, basedon the data in the look up table.

The invention allows a user, administrator and the like (herein referredto as a user) to manage and administrate a fleet of transmitters, RFdevices, transceivers, keyfobs and the like, and preferably a fleet ofkeyfobs, without the need to physically touch such devices in the field,for example.

More particularly, the system 300 in FIG. 12, is adapted for use withsecurity locks for containers, trailers, and delivery systems usingemergency exit doors, and provides an enhanced tool for managing,monitoring and administering RF devices, and particularly keyfobs,typically from a remote or dispatch office location. The look up tablecan be used to program when an RF device or keyfob is operable ornon-operable, and a logging feature can time stamp each device's usageor attempted usage, for later retrieval and analysis, which can beuseful for management of RF device fleets and field and deliverypersonnel. The performing or refraining from performing step includesentering data by a user, for example, in the look up table so as toenable or disable a desired RF device, and preferably a keyfob. Thisallows a user to enable real time a particular keyfob (e.g. theparticular keyfob is only programmed to operate during a first shiftbetween 9 a.m. and 5 p.m. and a certain field personnel is workingovertime and needs to complete assigned deliveries for the day after 5pm) or disable it (e.g. a keyfob is lost, stolen, or a particularemployee has terminated employment and has failed to return his or herassigned RF device or keyfob), typically from an office remote from thekeyfob.

In more detail, a user can manage a fleet of keyfobs in real time, byenabling or disabling a desired keyfob, monitoring one or more keyfobusers event activity, efficiency and location during the course of aday, week or month, for example. The system can enhance fleet managementand administration of RF devices and analysis of potential improvementsin field and delivery personnel productivity, real time or at a laterdate, for example.

In one embodiment, commands or attempted commands are logged from thetransmitter or keyfob based on its unique identified serial data.Advantageously, this information can be useful for productivityanalysis, process improvements for delivery and field personnel workflow during their normal work shifts and security, to name a few.

In more detail, a real time clock (RTC) can be utilized to accuratelyrecord the time of each event or attempted event, and a global positionsystem (GPS) receiver provides the location of each keyfob, inapplications when this type of detail is desired.

Advantageously, for improved security, a programmable work scheduleentry in the look up table is provided, to allow or restrict time anddays of usage for one or more keyfobs. In addition, to enable a certainkeyfob, a user may be required to enter a pass code comprising asequence of predetermined key entries, to enable a particulartransmitter or keyfob in the look up table, prior to sending a command.

In one embodiment, detecting a low transmitter battery state, loggingthat state and alerting a user of that state, can be useful in alertingsuch users that their RF device or keyfob battery needs to be rechargedor otherwise replaced. In a preferred embodiment, the sending stepincludes sending a sync counter value incremented after eachtransmission; the verifying step includes comparing the received synccounter value with the stored value in the look up table, and if theverification is valid the look up table value is updated, and otherwise,placing the received sync counter value in temporary storage in anauxiliary sync counter for a future resynchronization attempt; and theperforming step includes a command execution only if the sync counterverification is successful. This feature provides advantages in fleetmanagement.

In more detail, the verifying step further includes comparing thereceived sync counter value to the value from a temporary storage in theauxiliary sync counter, and if the value is verified, performing thedesired command and updating the sync counter look up table value, andif the value is not correct, ignoring the received command.

In a preferred embodiment, a custom keyfob management system isdisclosed. It includes the steps of: (i) sending a RF signal havingunique serial data from a transmitter; (ii) receiving the RF signal in areceiver and converting the RF signal to a digital signal; (iii)transmitting the digital signal with the unique serial data from thereceiver to a microcontroller; (iv) providing an editablemicrocontroller memory including a keyfob look up table accessible by anexternal computing device; (v) verifying whether the unique serial datafrom the transmitting step matches data populated in the look up table;(vi) providing at least one record structure in the look up table for atleast one keyfob, for recording parameters including at least one of aserial number, attributes, work schedule pointer, use counter, synccounter, auxiliary sync counter, and a cyclic redundancy check or acheck sum to verify each record's integrity; and (vii) performing orrefraining from performing a command requested by the keyfob, based onthe parameters in the look up table. This provides advantages in fleetmanagement.

In one application, the verifying step includes: processing the serialdata transmission by the microcontroller, and: (i) if the serial numberis known, defined by being stored in the look up table, an actuatingsignal is triggered and event logging of the requested command occurs;and (ii) if the serial number is unknown, defined by it not being storedin the look up table, and if a learning mode feature is activated, theunknown serial number is stored in a learning mode memory for subsequentprocessing, whereby a user can update the look up table to transform theunknown serial number which was stored, to a known serial number in thelook up table; and (iii) if the serial number is unknown and if thelearning mode feature is inactive, the command is processed by thereceiver only and ignored by the microcontroller. This is another fleetmanagement feature.

In one application as illustrated in FIG. 8, the verifying stepincludes: (i) preprogramming a work schedule table with at least onerecord containing data for each day of the week, and shorter timeperiods for each day, wherein table entry of one logic level indicatespermission to use, and a second logic level indicates lack of permissionto use; (ii) using the work schedule pointer from the keyfob look uptable and a real time clock, to retrieve the applicable work scheduletable entry and (iii) determining if the keyfob is allowed to be used.This structure allows an administrator to preset when the keyfob isenabled or disabled, as appropriate for a certain field worker. Thus, inmore detail, during normal work hours it can be enabled and after workhours disabled, as shown in FIG. 8. This feature provides enhancedsecurity for delivery and service companies, desiring keyfobs and RFdevices, to only be enabled at certain pre-set times.

In another preferred embodiment, the verifying step includes: (i)detecting potential record corruption by use of the cyclic redundancycheck or the check sum; (ii) providing a redundant keyfob managementtable in a different memory location and substantially continuouslyupdating the redundant management table; (iii) switching to theredundant table when corruption is detected and logging the keyfobmanagement table error to be fixed at a user maintenance interval. Thisprovides yet another fleet management feature, as should be appreciatedby those skilled in the art.

The verifying step can include: (i) detecting potential recordcorruption by use of the cyclic redundancy check or the check sum; (ii)providing a redundant keyfob management table in a unique memorylocation and substantially continuously updating the redundantmanagement table; (iii) using the redundant table record, if it iscorrect, to repair the corrupted record in a main table; (iv) loggingthe keyfob management table error automatically as fixed.

In more detail in FIG. 7, the verifying step can include the look uptable having a record structure including: a keyfob serial number, anenable bit to enable the transmitter, lost or stolen bit to disable thetransmitter, sync required bit, whereby if a transmitter is out of syncthe microcontroller stores the current transmitter's sync counter in anauxiliary sync counter, and if a subsequent transmission provides acorrect sync counter value, that clears the sync required bit to allow acorrect sync counter value to be transferred to the sync counter, passcode bit, whereby a key fob user is required to enter a predeterminedsequence of pushbutton activations (password) to set the pass bit totemporarily enable the transmitter for a certain period of time, and anew keyfob bit.

As illustrated in FIG. 10, the system can further comprise the step ofinterfacing with the microcontroller's memory, by: coupling an externalcomputing device with the microcontroller's memory; retrieving thekeyfob table from the microcontroller memory for at least one ofdisplaying, editing and filing; writing substantially the entire keyfobtable, or changes only, back to the microcontroller memory; exportingthe retrieved table to a spreadsheet or database program for additionalprocessing, including adding user's names. Advantageously, thesefeatures allow a user to dynamically manage and administer a fleet ofkeyfobs and RF devices.

In one embodiment, the system can include a step of interfacing with themicrocontroller's memory, by: coupling an external computing device withthe microcontroller's memory; retrieving the keyfob table from themicrocontroller memory for displaying, editing, and filing purpose;writing substantially the entire keyfob table, or changes only, back tothe microcontroller memory; exporting the retrieved table to aspreadsheet or database program for additional processing, includingadding user's names; providing a learning mode feature when activated,to send keyfob serial numbers to the computing device for keyfob tablecreation and addition to it; providing an automatic sorting of keyfobserial numbers when the new keyfob is added, in order to always writethe keyfob table records back to the microcontroller memory in anascending or descending order for facilitating searching; providing aread only learning mode feature when activated, to send keyfob serialnumbers to the computing device for keyfob identification in the keyfobtable. These features provide more flexibility and user friendly optionsfor a user.

In yet another embodiment, the step of interfacing with themicrocontroller's memory includes: coupling an external computing devicewith the microcontroller's memory; retrieving the keyfob table from themicrocontroller memory for at least one of displaying, editing andfiling; and displaying the information for user review including atleast one of serial number, work schedule, lost keyfob, new keyfob, synckeyfob, use counter, assigned to and keyfob ID, thereby simplifying themonitoring, administering and managing of a fleet of keyfobs.

The interfacing step can be accomplished by providing a communicationinterface adapted to allow the microcontroller to communicate with acomputing device through a serial communication link including at leastone of an RS-232, RS485 and USB.

Advantageously, the system allows easy interfacing with themicrocontroller's memory with a fleet control user/administrator, by:recording the serial data in the transmitting step, from the keyfob tothe RF receiver, including at least one of transmitter serial number,sync counter, low battery and a button pressed; providing acommunication interface adapted to allow the microcontroller tocommunicate with a computing device; providing a serial communicationlink, between the microcontroller's memory and the computing device; andmanaging, administering and monitoring a fleet of keyfobs by a user,either remotely from the keyfobs at a fleet control center or in thefield. These features provide enhanced flexibility from a fleetadministration and management perspective.

Likewise, the custom system can include the steps of: interfacing withthe microcontroller's memory with a fleet control administrator, by:coupling a computing device with the microcomputer's memory; displayinginformation from the microcontroller's memory on a monitor; and editingand monitoring the information displayed on the monitor, therebysimplifying and expediting the administration and management of a fleetof keyfobs, by including at least one or more and preferably most if notall of the steps of: providing a lost keyfob feature comprising a meansfor in the event a particular keyfob is lost, the ability to eliminatethe particular lost keyfob, without affecting the remaining keyfobs inthe fleet; providing a found key fob feature comprising a means for inthe event a particular keyfob is found, the ability to reinstate theparticular found keyfob, without affecting the remaining keyfobs in thefleet, substantially free from having to reprogram the particular foundkeyfob; providing a disable keyfob feature comprising a means for in theevent a particular disabled keyfob is attempted to be used, the abilityto detect and log it's attempted use including time stamping and GPSlocation; providing a low battery keyfob feature comprising a means fordetecting and warning a user of a low keyfob battery condition;providing an individual work schedule keyfob feature comprising a meansfor setting up an individual work schedule for each user, based onavailable work schedule tables; providing a pass code keyfob featurecomprising a means for authenticating a user by requiring entry of apass code before a particular keyfob becomes enabled; providing a keyfoblogging feature comprising a means for logging important key foboperations for each keyfob in a fleet, including at least one of timestamping, command, GPS position, system status, voltages, temperature,and individual work schedule for each user, based on available workschedule tables; providing a feature to allow an administrator to worksubstantially independently or with a fleet of keyfobs; providing afeature to allow an administrator to work with PC software and standardspreadsheet programs; and providing a feature to create at least oneredundant backup table in the microcontroller's memory, and to checkvalidity of each entry using a cyclic redundancy check and to repair adetected defective entry using the at least one backup table. Thesesteps, features, enhancements and structure, significantly simplifyfleet management of transmitters and RF devices, and particularlykeyfobs.

Those skilled in the art will recognize that a wide variety ofmodifications, alterations and combinations can be made with respect tothe above described embodiments without departing from the spirit andscope of the invention, and that such modifications etc. are to beviewed as being within the ambit of this invention.

1. An intelligent keyfob management system including at least one RFtransmitter, a RF receiver, and a microcontroller, comprising: sending aRF signal having unique serial data from a transmitter; receiving the RFsignal in a receiver and converting the RF signal to a digital signal;transmitting the digital signal with the unique serial data from thereceiver to a microcontroller; providing an editable microcontrollermemory including a look up table accessible by an external programmingdevice; verifying whether the unique serial data from the transmittingstep matches data populated in the look up table; and performing orrefraining from performing a command requested by the transmitter, basedon the data in the look up table.
 2. The keyfob management system ofclaim 1, wherein the performing or refraining from performing stepincludes entering data in the look up table so as to enable or disableat least one keyfob.
 3. The keyfob management system of claim 1, furthercomprising logging commands or attempted commands from at least onekeyfob and identifying each keyfob based on its serial data.
 4. Thekeyfob management system of claim 1, further comprising logging commandsor attempted commands from at least one keyfob, identifying each keyfobbased on its serial data, and recording time and location of each keyfobevent by using a real time clock (RTC) and a global position system(GPS) receiver.
 5. The keyfob management system of claim 1, wherein theproviding step further includes: providing a programmable work scheduleentry in the look up table to allow or restrict time and days of usageof at least one keyfob.
 6. The keyfob management system of claim 1,further comprising: requiring a user to enter a pass code comprising asequence of predetermined key entries, to enable at least one of thetransmitters in the look up table prior to sending a command.
 7. Thekeyfob management system of claim 1, further comprising: detecting a lowtransmitter battery state, logging that state and alerting a user ofthat state.
 8. The keyfob management system of claim 1, furthercomprising: providing a communication interface adapted to allow themicrocontroller to communicate with an external computing device.
 9. Thekeyfob management system of claim 1, further comprising: encrypting theRF signal from the keyfob and decrypting the RF signal in the receiver.10. The keyfob management system of claim 1, wherein: the sending stepincludes sending a sync counter value incremented after eachtransmission; the verifying step includes comparing the received synccounter value with the stored value in the look up table, and if theverification is valid the look up table value is updated, and otherwise,placing the received sync counter value in temporary storage in anauxiliary sync counter for a future resynchronization attempt; and theperforming step includes a command execution only if the sync counterverification is successful.
 11. The keyfob management system of claim10, wherein the verifying step further includes comparing the receivedsync counter value to the value from a temporary storage in theauxiliary sync counter, and if the value is verified, performing thedesired command and updating the sync counter look up table value, andif the value is not correct, ignoring the received command.
 12. Anintelligent keyfob management system including at least one RFtransmitter, a RF receiver, and a microcontroller, comprising: sending aRF signal having unique serial data from a transmitter; receiving the RFsignal in a receiver and converting the RF signal to a digital signal;transmitting the digital signal with the unique serial data from thereceiver to a microcontroller; providing an editable microcontrollermemory including a keyfob look up table accessible by an externalcomputing device; verifying whether the unique serial data from thetransmitting step matches data populated in the look up table; providingat least one record structure in the look up table for at least onekeyfob, for recording parameters including at least one of serialnumber, attributes, work schedule pointer, use counter, sync counter,auxiliary sync counter, and a cyclic redundancy check or a check sum toverify each record's integrity; and performing or refraining fromperforming a command requested by the keyfob, based on the parameters inthe look up table.
 13. The keyfob management system of claim 12, whereinthe performing or refraining from performing step includes entering datain the look up table so as to enable or disable at least one keyfob. 14.The keyfob management system of claim 12, further comprising loggingcommands or attempted commands from at least one keyfob and identifyingeach keyfob based on its serial data.
 15. The keyfob management systemof claim 12, further comprising logging commands or attempted commandsfrom at least one keyfob, identifying each keyfob based on its serialdata, and recording time and location of each keyfob event by using areal time clock (RTC) and a global position system (GPS) receiver. 16.The custom keyfob management system of claim 12, wherein the verifyingstep includes: processing the serial data transmission by themicrocontroller, and: if the serial number is known, defined by beingstored in the look up table, an actuating signal is triggered and eventlogging of the requested command occurs; and if the serial number isunknown, defined by it not being stored in the look up table, and if alearning mode feature is activated, the unknown serial number is storedin a learning mode memory for subsequent processing, whereby a user canupdate the look up table to transform the unknown serial number whichwas stored, to a known serial number in the look up table; and if theserial number is unknown and if the learning mode feature is inactive,the command is processed by the receiver only and ignored by themicrocontroller.
 17. The custom keyfob management system of claim 16,wherein the look up table created in the learning mode on one system andstored in a file can be loaded and utilized in one or more othermicrocontrollers and keyfob management applications.
 18. The customkeyfob management system of claim 12, wherein the verifying stepincludes: preprogramming a work schedule table with at least one recordcontaining data for each day of the week, and shorter time periods foreach day, wherein table entry of one logic level indicates permission touse, and a second logic level indicates lack of permission to use; usingthe work schedule pointer from the keyfob look up table and a real timeclock, to retrieve the applicable work schedule table entry anddetermining if the keyfob is allowed to be used.
 19. The custom keyfobmanagement system of claim 12, wherein the verifying step includes:detecting potential record corruption by use of the cyclic redundancycheck or the check sum; providing a redundant keyfob management table ina different memory location and substantially continuously updating theredundant management table; switching to the redundant table whencorruption is detected and logging the keyfob management table error tobe fixed at the user maintenance interval.
 20. The custom keyfobmanagement system of claim 12, wherein the verifying step includes:detecting potential record corruption by use of the cyclic redundancycheck or the check sum; providing a redundant keyfob management table ina unique memory location and substantially continuously updating theredundant management table; using the redundant table record, if it iscorrect, to repair the corrupted record in a main table; logging thekeyfob management table error automatically as fixed.
 21. The customkeyfob management system of claim 12, wherein the verifying stepincludes the look up table having a record structure including: a keyfobserial number, an enable bit to enable the transmitter, lost or stolenbit to disable the transmitter, sync required bit, whereby if atransmitter is out of sync the microcontroller stores the currenttransmitter's sync counter in an auxiliary sync counter, and if asubsequent transmission provides a correct sync counter value, thatclears the sync required bit to allow a correct sync counter value to betransferred to the sync counter, pass code bit, whereby a key fob useris required to enter a predetermined sequence of pushbutton activationsto set the pass bit to temporarily enable the transmitter for a certainperiod of time, and new keyfob bit.
 22. The custom keyfob managementsystem of claim 12, further comprising: logging events in an eventmemory including at least one of an event name, system status,temperature, time stamping, main and auxiliary voltages, and attributes.23. The custom key fob management system of claim 12, further comprisinginterfacing with the microcontroller's memory being internal or exteriorto the microcontroller.
 24. The custom key fob management system ofclaim 12, further comprising interfacing with the microcontroller'smemory, by: coupling an external computing device with themicrocontroller's memory; retrieving the keyfob table from themicrocontroller memory for at least one of displaying, editing andfiling; writing substantially the entire keyfob table, or changes only,back to the microcontroller memory; exporting the retrieved table to aspreadsheet or database program for additional processing, includingadding user's names.
 25. The custom keyfob management system of claim12, further comprising interfacing with the microcontroller's memory,by: coupling an external computing device with the microcontroller'smemory; retrieving the keyfob table from the microcontroller memory fordisplaying, editing, and filing purpose; writing substantially theentire keyfob table, or changes only, back to the microcontrollermemory; exporting the retrieved table to a spreadsheet or databaseprogram for additional processing, including adding user's names;providing a learning mode feature when activated, to send keyfob serialnumbers to the computing device for keyfob table creation and additionto it; providing an automatic sorting of keyfob serial numbers when thenew keyfob is added, in order to always write the keyfob table recordsback to the microcontroller memory in an ascending or descending orderfor facilitating searching; providing a read only learning mode featurewhen activated, to send keyfob serial numbers to the computing devicefor keyfob identification in the keyfob table.
 26. The custom key fobmanagement system of claim 12, further comprising interfacing with themicrocontroller's memory, by: coupling an external computing device withthe microcontroller's memory; retrieving the keyfob table from themicrocontroller memory for at least one of displaying, editing andfiling; and displaying the information for user review including atleast one of serial number, work schedule, lost keyfob, new keyfob, synckeyfob, use counter, assigned to and keyfob ID, thereby enabling a fleetof keyfobs to be monitored and managed by the user.
 27. The custom keyfob management system of claim 12, further comprising interfacing withthe microcontroller's memory, by providing a communication interfaceadapted to allow the microcontroller to communicate with a computingdevice including at least one of a personal computer, a wireless linkand a personal data assistant.
 28. The custom key fob management systemof claim 12, further comprising interfacing with the microcontroller'smemory, by providing a communication interface adapted to allow themicrocontroller to communicate with a computing device with a serialcommunication link including at least one of an RS-232, RS485; and USB.29. The custom keyfob management system of claim 12, further comprising:interfacing with the microcontroller's memory with a fleet controladministrator, by: recording the serial data in the transmitting step,from the keyfob to the RF receiver, including at least one oftransmitter serial number, sync counter, low battery and a buttonpressed; providing a communication interface adapted to allow themicrocontroller to communicate with a computing device; providing aserial communication link, between the microcontroller's memory and thecomputing device; and managing, administering and monitoring a fleet ofkeyfobs by a user, either remotely from the keyfobs at a fleet controlcenter or in the field.
 30. The custom key fob management system ofclaim 12, further comprising: interfacing with the microcontroller'smemory with a fleet control administrator, by: coupling a computingdevice with the microcomputer's memory; displaying information from themicrocontroller's memory on a monitor; and editing and monitoring theinformation displayed on the monitor, thereby administering and managinga fleet of keyfobs, by including at least one or more of: providing alost keyfob feature comprising a means for in the event a particularkeyfob is lost, the ability to eliminate the particular lost keyfob,without affecting the remaining keyfobs in the fleet; providing a foundkey fob feature comprising a means for in the event a particular keyfobis found, the ability to reinstate the particular found keyfob, withoutaffecting the remaining keyfobs in the fleet, substantially free fromhaving to reprogram the particular found keyfob; providing a disablekeyfob feature comprising a means for in the event a particular disabledkeyfob is attempted to be used, the ability to detect and log it'sattempted use including time stamping and GPS location; providing a lowbattery keyfob feature comprising a means for detecting and warning auser of a low keyfob battery condition; providing an individual workschedule keyfob feature comprising a means for setting up an individualwork schedule for each user, based on available work schedule tables;providing a pass code keyfob feature comprising a means forauthenticating a user by requiring entry of a pass code before aparticular keyfob becomes enabled; providing a keyfob logging featurecomprising a means for logging important key fob operations for eachkeyfob in a fleet, including at least one of time stamping, command, GPSposition, system status, voltages, temperature, and individual workschedule for each user, based on available work schedule tables;providing a feature to allow an administrator to work substantiallyindependently or with a fleet of keyfobs; providing a feature to allowan administrator to work with PC software and standard spreadsheetprograms; and providing a feature to create at least one redundantbackup table in the microcontroller's memory, and to check validity ofeach entry using a cyclic redundancy check and to repair a detecteddefective entry using the at least one backup table.
 31. An intelligentkeyfob management system including at least one RF transmitter, a RFreceiver, and a microcontroller, comprising: sending a RF signal havingunique serial data from a transmitter; receiving the RF signal in areceiver and converting the RF signal to a digital signal; transmittingthe digital signal with the unique serial data from the receiver to amicrocontroller; providing an editable microcontroller memory containinga keyfob look up table accessible by an external computing device;verifying whether the unique serial data from the transmitting stepmatches data populated in the look up table; providing at least onesensing input signal to the microcontroller from the RF receiver; andperforming or refraining from performing a command requested by thekeyfob, based on at least one of the data in the look up table or atleast one sensed input signal to the microcontroller.